FIG. 1 is a Policy and Charging Control (PCC) defined by a 3rd Generation Partnership Project (3GPP).
A Policy and Charging Rules Function (PCRF) is to make the Quality of Service (QoS) and a charging policy for a service by using network resources. The PCRF needs to make the control policy in combination with service information received from an AF, subscription information received from a Subscription Profile Repository (SPR), a policy configured by an operator, etc. The PCRF issues a control policy made for the service to a Policy and Charging Enforcement Function (PCEF) or a Bearer Binding and Event Report Function (BBERF) to be executed. Meanwhile, the PCRF may subscribe the PCEF and/or the BBERF for a traffic plane related event, such that when the event occurs in a traffic plane, the event is perceived in time, and the control policy is changed. Besides, the PCEF and a Traffic Detection Function (TDF) can execute an application detection and control function according to a PCC rule (PCEF) or ADC rule (TDF) issued by the PCRF.
With the development of mobile internet, an operator needs to intercommunicate with a third-party data application provider, and performs QoS guarantee on a service provided by the third-party data application provider. Since an Rx interface supported by the PCC currently adopts a Diameter protocol, most of third-party data application providers are more skilled in development based on SOAP and REST protocols. At present, the industry researches a PCC architecture to support an Rx interface based on the SOAP/REST protocol. Two solutions are proposed, one solution is that the PCRF supports the SOAP or REST protocol, and another solution is that the PCRF and the AF directly provide a network element called as a Protocol Converter (PC) for converting the SOAP or REST protocol into Diameter. At present, the SOAP protocol supports an Extensible Markup Language (XML), and the REST protocol supports the XML and a JavaScript Object Notation (JSON) language.
The Rx interface needs to support two-way communication. That is, the AF provides service information for the PCRF, and the PCRF needs to provide a traffic plane event for the AF in real time. However, the SOAP or REST protocol is based on a Hypertext Transfer Protocol (HTTP). The HTTP is a stateless protocol, a client requests for a Uniform Resource Locator (URL), a server gives a response and sends response content, and a port is connected, but two-way communication cannot be implemented. In order to make the server actively push information to the client, the industry proposes the following three solutions at present.
1. Polling: a browser continuously sends a request to obtain latest data to simulate into push. The solution is disadvantageous in large delay and high signaling overhead.
2. Streaming: after the server receives an HTTP request of the client and returns an acknowledgement message, the connection between the server and the client is not disconnected, and the server may continuously send data to the client via the connection. The solution is disadvantageous in occupation of resources of the server and the client due to maintenance of the connection. Its Proxy support is not good, because a proxy may cache data.
3. Long-Polling: the browser sends a request, after receiving the request, the server hangs the connection until there is data needing to be sent to the client, and after the data is completely sent, the connection is disconnected; and the client receives the data, and requests the server again to take data. The solution is disadvantageous in occupation of the resources of the server and the client due to maintenance of the connection.
In view of a special application of the PCC, a third-party data application needs to provide service for a great number of users. Therefore, if the Streaming or Long-Polling solution is used, a great number of Transmission Control Protocol (TCP) connections need to be kept between a third-party data application server and the PCRF or PC.
Besides, in a related protocol, it is also provided that at most two HTTP TCP connections can be kept between an identical client and server. If more than two HTTP TCP connections are kept, it is inconsistent with the related protocol, thereby causing the problem of conductivity.
The related technology also proposes that a plurality of HTTP requests may be packaged into a TPC connection (becoming HTTP Pipelining), and the server can actively provide data to the client in a Long-Polling mode. However, the solution requires that the client may send a new request only after Long-Polling is completed, which may cause a delay.